Requirements for Taking Applications Beyond the Enterprise

Graeme Port
Clifford Heath
Phillip Merrick
Tim Segall

Abstract

This paper presents the main facilities that are required or highly desirable for organizations to be able to use the Web to deploy their applications beyond the enterprise. Some of these facilities have not been getting sufficient attention from the Web community. We highlight a number of important issues in relation to these facilities. In many cases, these facilities are well understood by the User Interface Management System vendors who have developed specialized front-end systems for the development of internal corporate applications. We believe that these systems will play an important role in the deployment of Web applications.

Keywords: WTW, UIMS, structured data interface, mobile code, transaction integrity

Introduction

A recent report from Forrester Research [3] suggests that the World Wide Web (WWW) will evolve into something they dub the Worldwide Transaction Web (WTW). In addition to providing the largely non-interactive hyperlinked documents that constitute the current WWW, the WTW will permit corporations and government organizations to allow customers and suppliers access to selected internal applications. The WTW will also trigger the development of a large number of new customer-oriented service applications.

This paper presents what we see as the major facilities (in terms of service infrastructure and application development tools) that are required or highly desirable for the deployment of these applications.

The following facilities are required:

The following facilities are highly desirable: This list differs from the topics currently receiving most of the attention in the WWW community, but it does match quite closely with the main issues confronting the client/server cross-GUI User Interface Management Systems (UIMSs), such as OpenUI [6]. These systems are widely adopted in business for internal application development. It is our opinion that they will play an important role in the evolution of the WTW.

This paper presents in considerable depth the major issues related to the facilities listed above. But first we describe a real-world example to help highlight the particular concerns in the business community to the development of WTW applications.

A Real-world Example

A major telecommunications company offers a complex array of products and services. Their order entry application has extensive validation requirements for cross-checking the various items and options selected to ensure that each order has a valid configuration before it is submitted for processing. A single order could be up to 20 screens of data, and there are approximately 3,000 validation rules to be applied. All orders are currently entered by operators taking calls from customers, but the company wants to allow its customers to enter orders directly.

The architecture manager states the specific requirements as:

"It needs to be as easy to access and use as the average Web page, but with all the GUI facilities, power and front-end validation possible in any installed stand-alone program. We'd also prefer to be able to develop just one version of the application to support both our own operators and our customers, even though they have different access and usability requirements."
Consider the following scenario for meeting the architecture manager's requirements:
  1. The user has been browsing the company's Web page and decides to place an order so they select Order Entry, which is a link to the order application viewer program.
  2. The browser checks that the requisite support objects are already present to allow the application viewer to run, such as other mobile code objects or a generic application viewer. If not already present, these items are downloaded from a well-known FTP site and automatically configured.
  3. The application viewer starts by making a network connection to an application server program running on the corporate Web server machine outside the corporate network.
  4. The application server program makes an appropriate "pass through" network connection to an internal application server running on one of the internal corporate machines.
  5. The application presents its main window and is now ready for the user to run.
This sequence of steps can be traced in Figure 1.


Figure 1: Connecting to a corporate application

The application viewer itself might be:

There will be situations where a custom application is appropriate, despite the requirement to support multiple versions for various hardware types and operating systems. For instance, a bank with hundreds of thousands of customers might be prepared to develop a custom home banking application for the use of its customers only. In particular market segments, independent software vendors might create custom applications for sale to a number of companies.

However, most application viewers (by number) will be modules of mobile code in one of the latter two classes. As we will see, some existing client/server cross-GUI UIMSs provide all the features required for client-side processing and can be used as the basis for generic application viewers.

Full-function GUI

Modern GUI tool kits provide an array of user interface controls (including buttons, edit texts, menus, combo-boxes and low-level graphics) allowing developers to build intuitive and productive interfaces. These controls can be arranged across multiple windows, and can be dynamically reconfigured to allow optimal presentation and direct manipulation of complex data.

In contrast, HTML Forms provide access to just a limited subset of these controls, and the only arrangements possible are static aggregations of the simplest kind. The basic model is along the lines of "fill out the form and press the submit key", a regression to the mainframe block-mode display terminal interfaces of old.

To be successful, WTW applications need to support the full range of user interface controls currently available in stand-alone applications.

One of the most important features required for a full-function GUI on the WTW is cross-GUI support. Users may have a variety of GUI environments, including Microsoft Windows, Apple Macintosh, OSF Motif, and OS/2 Presentation Manager. On each GUI platform, the application must look and feel like an application built specifically for that platform. The challenge here is to develop a framework for specifying user interfaces generically, while dealing with the differences between the GUI standards. A "lowest common denominator"--supporting only those facilities common to all GUI standards--can only be used to construct very simple user interfaces.

The frameworks of some existing cross-GUI UIMSs allow the presentation of GUI-independent user interfaces on a wide range of platforms.

Structured Data Interfaces

The rapid growth of the Web is testament to the simple elegance and power of HTML as a markup language and HTTP as a protocol for networked hypermedia documents. HTML, however, is a document markup language for describing documents to be read by humans. Writing software to extract data from HTML pages is comparatively difficult and easily broken by relatively minor changes to the content of pages.

WTW servers will need to present data in a manner that is easily parsed by the client software and relatively stable when changed. There are a number of ways this could be done with differing advantages and complexity. For example, the data could be presented:

The EDI format is in wide use in this type of application and could represent a suitable base from which to work.

For WTW applications to talk to a wide range of servers, a common structured data interface language and protocol must be adopted to play the equivalent role to HTML in the WWW. For the internal application server, it is much easier to communicate via a structured data interface than HTML. Many CGI programs are simply there to put an HTML wrapper around a few important data items contained in an HTML page. A WTW server will present the structured data directly.

The same structured data interface could be used by the client when it transfers data to the server, as is already done with the HTML Forms interface.

The database vendors are offering to provide HTML gateways to their databases in an attempt to increase the demand for database services. Unfortunately, giving end users direct access to flat, normalized tables in relational databases has not been a resounding success, as was amply demonstrated to the same vendors a decade ago. A much better approach is for the data from these databases to be presented through a structured data interface so that the WTW application can present the information in an appropriate way to the user.

Mobile Code

Mobile code executing on the client: Without general-purpose programming language code running on the client machine, the dynamics of a full-function GUI cannot be maintained. Without this facility the WWW could not scale-up to the demands of the WTW; if HTTP servers and CGI programs were to do all data validation and dialog management, the Internet and the server machines would become completely overloaded.

The commonly understood form of mobile code is typified by the Java language [4], and is usually considered as integrated into the Web browser. A code module for a generic application viewer external to the Web browser is also a form of mobile code.

There are existing UIMSs that store their user interface definitions--including associated mobile code--in machine-independent format. Downloading these definitions gives an effective mobile code deployment mechanism.

Security

Internal applications rely heavily on physical security for protection against eavesdropping, meddling and fraudulent access, but the Internet does not offer such security. Security on the Internet must rely instead upon cryptosystems such as SSL [5], S-HTTP [7], and IPng. These cryptosystems have been discussed at length in the literature and there are trial implementations available today.

SSL provides protection of privacy, data integrity and server authentication, but until suitable tools for certificate management and the implementation of trust policies are standardized, client authentication is left without adequate support. Nonetheless, security is a problem receiving a lot of attention from the WWW community that will, in all likelihood, be progressively solved over the next twelve months.

Transaction Integrity

The basic principles of transaction integrity are described by the so-called ACID properties: Even casual use of the Web demonstrates disturbing deficiencies in this area. Server hardware and software fail, or become hopelessly overloaded, communications links break, yet there are no mechanisms for ensuring the integrity of Web-based transactions.

The distributed computing community has already developed standards (for example, X/Open DTP Model and Standards, and CORBA2) and products (for example, Encina, Tuxedo, and Orbix) that address transaction integrity across internal corporate networks. It is unrealistic to expect every machine connected to the Internet to be equipped with the runtime libraries of all of these products. Instead what is needed is a lightweight and universal means of extending their protective umbrella out across the Internet.

UIMSs have shown their ability to integrate with these products and standards.

Highly Desirable Facilities

The issues related to the highly desirable facilities are presented somewhat more briefly.

Connection-oriented sessions

HTTP was designed as a light-weight protocol for transfer of documents. The browser opens a connection to a server, sends a single request, and waits for a response. The response arrives and the connection is closed. This is known as the request/response model.

There is a significant class of applications, however, for which the request/response model is unsuitable. These applications are connection-oriented, and often follow the client/server model. Most interactive applications fall into this category. For these applications it makes sense to keep a connection open for the duration of the session. An added benefit is the elimination of the overhead of setting up a connection and initializing the server process for each exchange of data.

A closely related issue concerns the limitations of HTTP and CGI to represent the state of an application. This has prompted the development of mechanisms like Persistent Client State HTTP Cookies [1]. These allow the server to store state information in a client, which then sends this state with each request to the server.

Storing state is one way of allowing a virtual connection to be maintained, even if several physical connections have to be opened and closed.

Same tool for internal and external development

It is increasingly clear that the Internet represents the next frontier for application development. Given the limited resources available to many corporate IT departments, it is unreasonable to expect that they will use different technologies for developing internal and external applications.

We can anticipate a need for a single technology that meets the requirements for both internal and external application deployment.

The WTW requirements closely match those of a client/server cross-GUI UIMS tool, implying that such a tool may be the best candidate for unifying internal and external development. Such an approach is certain to find more acceptance than attempting to use a browser-embedded mobile code interface for internal applications.

Graphical application-builder tool

Building the user interface of an application is much easier if it is visible on the screen so that the effect of each change can be seen immediately. It is important that the user interface is not mocked up, but is displayed exactly as it will appear in the running application, otherwise there may be differences and errors that are time-consuming to fix.

Application internationalization support

Many global companies will deploy their applications in multiple languages. The process of modifying an application to operate in a different human language or with different cultural conventions is called localization. This has increasing relevance in today's business environment.

A subtle problem with internationalization is that translated text is often different in length from the original. For example, German text is, on average, 30% longer than its English equivalent. If pixel-based geometry is used, the alignment of text and fields is spoilt by the translation.

At least one UIMS has solved this problem by arranging the UI elements into a "logical grid", where UI objects manage their positioning in relation to one another by occupying cells in the grid. This gives a highly portable mechanism for geometry management.

Conclusion

This paper has presented what we see as the major facilities that are required or highly desirable for the evolution of the WTW to take place.

Required facilities: full-function graphical user interface, structured data interfaces, mobile code, security, and transaction integrity.

Highly desirable facilities: connection-oriented sessions, same tool for internal and external development, graphical application builder tool, and application internationalization support.

A number of these facilities are well met by existing client/server cross-GUI UIMSs already being used for internal application development. We predict that these systems will play a major role in the development of the WTW and taking applications beyond the enterprise.

References

1. Persistent Client State, HTTP Cookies, Netscape Communications Corp., 1995. http://www.netscape.com/newsref/std/cookie_spec.html

2. Richard Dratva, WWW-based Home Banking in Switzerland: A Case Study, Proceedings of the 2nd WWW Conference '94: Mosaic and the Web, October 1994. http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/ComEc/dratva/dratva.html

3. The Forrester Report: CIO Meets Internet, May 1995, Forrester Research Inc., Cambridge MA.

4. The Java Project, Sun Microsystems, Inc., 1995. http://java.sun.com/

5. The SSL Protocol, Draft Specification, Netscape Communications Corp., February 1995. http://www.netscape.com/newsref/std/SSL.html

6. OpenUI Technical Overview, Open Software Associates, Ringwood, Australia, November 1993.

7. E. Riscorla and A. Schiffman, The Secure Hypertext Transfer Protocol, Internet Draft, December 1994. http://www.eit.com/projects/s-http/shttp.txt

About the Authors

Graeme Port
Open Software Associates,
29 Ringwood Street,
Ringwood 3134 Victoria,
Australia
<gsp@osa.com.au>

Clifford Heath
Open Software Associates,
29 Ringwood Street,
Ringwood 3134 Victoria,
Australia
<cjh@osa.com.au>

Phillip Merrick
Open Software Associates,
29 Ringwood Street,
Ringwood 3134 Victoria,
Australia
<phjm@osa.com.au>

Tim Segall
Open Software Associates, Inc,
20 Trafalgar Square, Fifth floor
Nashua NH 03063
USA
<tim@osa.com>